🟡 Heimdall Review Status

Reviewed the fix — the analysis in #377 is correct and failing early is the right call. The two-branch if returning the same value was clearly unfinished (// TODO: support creating factory data), and silently handing viem { factoryData: undefined } defers the failure to bundler simulation where the error message ("account not deployed" / AA20) gives no hint that the root cause is a missing SDK parameter.

Also agree that deriving factoryData locally is unsafe: createAccount(bytes[] owners, uint256 nonce) needs the full owner set and nonce, and reconstructing that from a single owner + ownerIndex risks computing factory data for a different deterministic address than the one the account object was created with — a silent wrong-account deployment is strictly worse than a thrown error.

One edge case worth verifying before merge: getFactoryArgs() is not only called on the deploy path. viem also calls it when wrapping signatures in ERC-6492 format for undeployed accounts (signMessage/signTypedData on a counterfactual account produce a 6492-wrapped signature embedding factory + factoryData). If any SDK flow signs with an undeployed smart account that was created without factoryData, this change moves the failure from "invalid 6492 signature that fails verification downstream" to "throw at signing time". That's still the better behavior — but it means the error can now surface in sign flows, not just deploy flows, so the error message could mention both. Suggestion:

'Cannot generate factory args for an undeployed smart account: factoryData was not
provided and cannot be derived locally. Deployment and ERC-6492 signing both
require factoryData for undeployed accounts.'

Worth grepping the SDK for getFactoryArgs call sites (including via viem's toSmartAccount internals) to confirm which flows can hit the throw, and adding one test for the signing path if it applies. Otherwise LGTM — the regression tests cover both branches and the behavior change is strictly an improvement in failure locality.